Resource reservation protocol (RSVP) traffic engineering (RSVP-TE) graceful restart (GR) scheme provides a mechanism to preserve a label switched path (LSP) during a control plane failure of a network element or network node so that traffic is not impacted. Further detailed information regarding the RSVP GR specification can be found in several request for comments (RFCs) such as RFC-3473 and RFC-5063.
RSVP fast reroute (FRR) scheme is specified in RFC-4090 and provides a fast local repair mechanism when link or node failure occurs so that the traffic can be switched on a point of local repair (PLR) node to a pre-established bypass tunnel from the protected LSP for facility protection. A merge point (MP) node merges the traffic back to the protected LSP. The bypass tunnel can provide the FRR protection for multiple protected LSPs (1:N protection). When the FRR is in effect, the traffic could stay in the bypass path for an extended period of time. During this period of time, if the PLR node or MP node restarts, the RSVP GR procedures cannot be applied because no HELLO message is exchanged between the PLR node and the MP node if the MP node is not directly connected with the PLR node. As defined in RFC-3209, an RSVP HELLO session is running between immediate neighboring nodes only.
According to RFC-3209, RSVP HELLO messages are exchanged between directly connected neighboring nodes to detect the health of a control plane of the neighboring nodes. RFC-3473 extends the RSVP HELLO mechanism to support RSVP Graceful Restart functionality. A HELLO message is used to carry a graceful restart capability object and information that is used to preserve the LSP and recover the LSP state after a control plane of a network element fails or restarts. If the HELLO session is not established, the graceful restart cannot be achieved. RFC-4558 introduces node-id based HELLO messages.